『Amazon Redshift&Tableau パフォーマンスチューニング』に関するホワイトペーパーの改訂版を読んでみた（Amazon Redshiftの最適化編）

「カスタマーストーリー」を支えるツール特集

#Tableau

#Amazon Redshift

#AWS

石川覚

2018.02.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

Tableau Software社が公開しているホワイトペーパーの改訂版『Tuning your Amazon Redshift and Tableau Software Deployment for Better Performance v2』が公開されていますので、数回に分けてそのポイントについて紹介します。今回はテーマは、「Amazon Redshiftの最適化」です。

ドキュメントのダウンロードは、以下のリンクをクリックして、ログインした後ダウンロードできます。

Optimizing your Amazon Redshift and Tableau Software Deployment for Better Performance v2

Amazon Redshiftの最適化

Amazon Redshift-TableauのAmazon Redshiftを最適化する際には、データベース自体を単純化と、Amazon RedshiftをTableauとどのように統合するかを具体的に最適化の２つに重点を置きます。Amazon Redshiftや他のカラムナデータベースの場合は、結合の数が減り、テーブルスキーマの非正規化が行われ、ディメンションテーブルがファクトテーブルにマージされ、テーブルの列サイズができるだけ狭くなります。これらのすべてがクエリのパフォーマンスを向上させます。

Tableauとの最良のインテグレーションのために、あなたが進めようと計画している分析作業について学びます。データのすべての列が同じ重要度であるわけではなく、どのフィールドが最も頻繁に使用され、最も重要なのかを知ることで、Amazon Redshiftを最適化して、ソートキー、分散キーなどフィールドの優先順位付けができます。Amazon Redshiftを初めてお使いの方は、以下の概念と考慮事項の多くを詳しく解説したシステム概要をお読みください。

パフォーマンスチューニングに関する補足事項:

Amazon Redshift クラスタの構築

Amazon Redshiftの現行クラスタは、2つのサイズのノードタイプが2つあり、合計4つのクラスタオプションがあります。各オプションは、特にコンピューティングパワー、メモリ、およびストレージに関するクラスタの機能に影響します。次に、各機能はクエリの速度とTableauダッシュボードのテーブル示にかかる時間を考慮します。

高密度ストレージノード（DS2）

ハードディスクドライブ（HDD）を使用して非常に大規模なデータウェアハウスを作成する用途のノードタイプです。

Node Size	vCPU	ECU	Memory (GiB)	Storage	Node Range	Slices	Total Capacity
ds2.xlarge	4	13	31	2 TB HDD	1–32	2	64 TB
ds2.8xlarge	36	119	244	16 TB HDD	2–128	16	2 PB

高密度コンピューティングノード（DC2）

高速CPU、大量のRAMおよびソリッドステートドライブ（SSD）を使用して非常に高性能なデータウェアハウスを作成する用途のノードタイプです。

Node Size	vCPU	ECU	Memory (GiB)	Storage	Node Range	Slices	Total Capacity
dc2.large	2	7	15.25	0.16 TB NVMe-SSD	1–32	2	5.12 TB
dc2.8xlarge	32	99	244	2.56 TB NVMe-SSD	2–128	16	326 TB

dc1.large Amazon Redshiftクラスタを使用している場合は、既存のスナップショットを使用して新しいdc2.largeクラスタに単純にリストアできます。 dc2.xlarge、dc2.8xlarge、またはdc1.8xlargeのAmazon Redshiftクラスタから移行するには、サイズ変更操作を使用して新しいDC2クラスタにデータを移動します。詳細については、Amazon Redshiftのクラスタとノードを参照してください。

DC2ファミリは、1ノードしか必要としない1TB未満のデータウェアハウス用に、コスト効率の高い小さなノードを用意しています。コンピューティング重視のノードを使用すると、同じデータに対する同じクエリが大幅に高速化され、結果としてTableauワークブックのパフォーマンスが向上します。

クラスタをスケールアウトしてノード数を増やすか、ノードサイズを拡大してより大きなノードに変更することで、クラスタの機能を向上させることができます。クラスタのサイジングの決定は、ダッシュボードをロードする速度とそれらのダッシュボードの複雑さ（実行する必要があるクエリの数）によって決まります。もちろん、クラスタのスケーリングはパフォーマンスを向上させますが、Amazon Redshiftを最適化するために時間を費やす必要があります。以下の調整や最適化を行わなくても、さらに多くのパフォーマンスが向上することはありません。

経験則として、多くのノードで効率的に複雑なクエリ（たとえば、多数の結合を含むクエリ）を実行する能力のためにDense Compute Nodes（DC2）を推奨します。スケールアップする前にスケールアウトを検討してください。

ソートキー、分散キー、列圧縮

Amazon Redshiftクラスタを構築した後、ソートキー、分散キー、列圧縮のチューニングをしてください。

ソートキー

ソートキーは、データがストレージに格納される順序を定義します。データがソート順の問い合わせすると、SQLのWHERE句でデータを効率的にフィルタできます。Tableau用に最適化されたAmazon Redshiftのソートはとても重要です。データがソートされているので関連のないデータのスキャンをスキップできるからです。

Amazon Redshiftでは、2つのソートキーがあり、異なる方法を使用して複数の列でデータを並べ替えることができます。

ソートキー：特定の順序でソートキーに使用されている列をリストします。
インターリーブドソートキー：ソートキーで使用されているすべての列に同じ重みを与えます。

Tableauを最適化するための上記のガイドラインに従っている場合、複合ソートキーの使用をお勧めします。 Tableauの最大の強みの1つは、分析作業を促進するダッシュボードを構築し、1つの質問に回答し、次に回答するデータをさらに表示します。複合ソートキーは、最初にソートキー内のデータを1つの列にしたがってソートし、その後に続く列をソートするという点で、これには最適です。

たとえば、salesデータセットの2つのフィールドを取る：ColorとProduct Type。おそらくColorは少数ですが、数千種類のProduct Typeがあります。ダッシュボードを設計して、ユーザーが最初にColorを分析し、次にProduct Typeを分析するように促す場合は、列の色が最初に選択され、次にProduct Typeが選択された複合ソートキーを簡単に作成できます。その結果、データを特定のColorに変換するクエリが大幅に改善され、特定の色とProduct Typeにデータを変換するクエリも可能になります。ただし、このソートキーは、Product Typeでのみクエリが送信される場合には効果が得られません。

ソートキーに指定された列が高度に選択的（高カーディナリティーとも呼ばれます）の場合、ソートキーに列をさらに追加してもほとんど効果がなく、保守コストがかかるだけです。この例では、Colorのカーディナリティが低いと想定できるため、Product Typeを追加するとメリットがあります。最初にProduct Type別にソートする場合は、ソートキーにColorを追加するとパフォーマンスが向上することはほとんどありません。

インターリーブドソートキーのキーはすべてキーの列に等しいウェイトが与えられますが、控えめに使用する必要があります。クエリは、任意の列を任意の順序で入力するように選択でき、ロードおよびVACUUM時間の増加の代わりにパフォーマンスを向上させる可能性があります。ColorとProduct Typeの例では、インターリーブドソートキーを使用すると、2つの列のいずれか、またはソートキーに追加された追加の項目にクエリを送信することができます。しかし、ほとんどの分析ワークフローでは、どの項目が最も重要で、最初に使用される可能性が高いかをほとんど常に把握しています（たとえば、DateまたはProduct Type、製品モデル番号など）。

ソートキーと分散キーに指定する列を決定する際に役立つ情報については、Amazon Redshift開発者ガイドのソートキーの選択を参照してください。

分散キー

分散スタイルと最適な分散キーを選択すると、テーブル結合のパフォーマンスが大幅に向上します。 Amazon Redshiftは、大規模並列処理（MPP）と呼ばれる複数のノード間で操作を並列化することで、大量のデータを処理します。この並列化は、テーブルのデータがクラスタ全体にどのように分散されるかを定義する3つの分散スタイル（EVEN、KEY、またはALL）の何れかを選択します。ソートキーと組み合わせると、慎重に計画された分散キーは、大きなパフォーマンス向上をもたらす可能性があります。たとえば、頻繁にテーブルを結合する場合は、結合列をソートキーと分散キーの両方として指定します。これにより、クエリオプティマイザは、より低速のハッシュ結合の代わりにソートマージ結合を選択できます。データはすでにジョイン・キーでソートされているため、クエリオプティマイザはソート・マージ結合のソート・フェーズをバイパスすることができ、Amazon Redshiftは列内の個々の項目ごとに少ないデータをスキャンできます。

分散キー用に指定する列の決定に役立つ情報は、Amazon Redshift開発者ガイドのデータ配布方法の選択を参照してください。

データを分散する際の方針として、2つの目標が必要です。

ノード間のデータの移動を最小化する。 2つのテーブルが頻繁に結合されることが多い場合、クエリ時間を短縮するために、対応する結合データを同じノードにロードします。（すなわち、基本的に結合キーに従い分散する）
テーブルのデータを均等に配布する。不均等分布は、データ分散スキューとも呼ばれ、あるノード上のデータが他のノードよりも多く存在することを意味します。これは、クエリのパフォーマンスに悪影響を及ぼします。データの分散スキューをテストする簡単な方法の1つは、Tableau自体でそれを視覚化することです。潜在的な分散キーフィールドに基づいてAmazon Redshiftのバケットデータを作成し、Tableauでそれに接続します。

分散スタイル KEY

大きなテーブルの一般的な配布スタイルはKEYです。テーブルを作成するときに、テーブル内の1つの列をKEYに指定します。同じキー値を持つすべての行は、常に同じノードに保存します。 2つのテーブルがKEY配布スタイルを使用する場合、同じキーを持つ両方のテーブルの行が同じノードに保存されます。つまり、結合された2つのテーブルがあり、結合で使用される列が分散キーの場合、結合された行は同じ物理ノードに配置されます。これにより、ノード間のデータ移動が少なくなるため、クエリーがより高速に実行されます。ファクトテーブルなどのテーブルが複数の他のテーブルと結合している場合は、そのテーブルが結合する最大の次元の外部キーに分散します。分散キーがテーブルデータを比較的均等に配布することを確認してください。

分散スタイル ALL

2番目の配布スタイルであるALLは、結合でのデータのコロケーションも促進します。このスタイルは、テーブルのすべてのデータをクラスタ内のすべてのノードに配布します。各ノードにデータをレプリケートするとストレージコストがかかり、ロード時間が長くなりますが、テーブルは常にどのジョインに対してもローカルになり、クエリのパフォーマンスが向上します。 ALLディストリビューションに適しているのは、小さなディメンションテーブルです。特にファクトテーブルと同じ分散キーキーを共有していない、スタースキーマ内の緩やかに変化するディメンションテーブルです。

分散スタイル EVEN

テーブルの作成時にDISTKEYを指定するか、テーブルを作成するときにdiststyle ALLを指定してALLの分散スタイルを選択しないと、テーブルデータはクラスター全体に均等に分散されます。これは、EVEN分散スタイルとして知られています。

ソートキーと分散キーに指定する必要があるテーブルの列を決定する際に役立つ情報については、Amazon Redshift開発者ガイドのデータ分散メソッドの選択を参照してください。

列圧縮

AmazonのRedshiftでのクエリのパフォーマンスに関しては、圧縮設定も大きな役割を果たします。 Amazon Redshiftは、カラム型圧縮を使用してデータI/Oとスペース要件を最適化します。これは、最初の100,000行のデータを分析して、空のテーブルにデータをコピーするときに各列に使用する圧縮設定を決定することによって行います。

ほとんどの場合、自動的に圧縮タイプを選択するために、Amazon Redshiftの自動認識に頼ってください（強くお勧めします）。上級ユーザーは、テーブルの作成時に各列の圧縮スキームを指定することにより、これらの設定をオーバーライドできます。列が適切に圧縮されていることを確認すると、より小さなクラスタにデータを格納できるため、読み取りごとに多くのデータを転送し、コストを削減できるため、クエリが高速になります。データのロードと圧縮オプションの制御の詳細については、Amazon Redshift 開発者ガイドの列圧縮タイプの選択と自動圧縮ありでテーブルをロードするを参照してください。

列圧縮する方法は２つあります。１つはCOPYコマンドのCOMPUPDATEオプションをON（デフォルト）に設定して、Amazon Simple Storage Serviceのデータをテーブルにロードするときに圧縮タイプを自動認識する方法です。もう１つはすでにデータが格納されているテーブルに対して、ANALYZE COMPRESSIONを実行して、列圧縮を自動診断させます。テーブルに格納されたデータが徐々にロードされるにつれて変化する場合は、定期的に圧縮分析を実行して、最適な圧縮設定があることを確認することも必要です。ソートキーの最初の列を圧縮しないでください。その結果、必要以上に多くの行をスキャンしてパフォーマンスが低下する可能性があります。

暗号化

Amazon Redshiftには、ハードウェアアクセラレーションによるAES-256暗号化を使用する暗号化オプションがあり、ユーザー制御の鍵ローテーションをサポートしています。Amazon Redshiftには、エンドユーザーと格納されたデータを持つノード間のセキュリティ分離のいくつかの層があります。たとえば、エンドユーザーは、データが格納されているAmazon Redshiftクラスタ内のノードに直接アクセスすることはできません。

暗号化の詳細については、Amazon Redshift 管理者ガイドのAmazon Redshift データベース暗号化を参照してください。

なお、このホワイトペーパーの中で、「パフォーマンスが平均20％低下し、最大オーバーヘッドは40％もあります。」という記載がありますが、Amazon Redshiftの最新の公式マニュアルではこの記載は削除されています。

テーブルの VACUUM と ANALYZE

多くのレコードの追加、更新、または削除を引き起こすデータをロードした後、VACUUMコマンドを実行してパフォーマンスを最適化する必要があります。 VACUUMは、２つの目的があり、１つは削除されたアイテムのスペースを再利用すること、もう一つはデータがディスク上で正しくソートされるようにします（テーブルがソートキーを定義していることを前提とします）。ロード操作後にVACUUMを実行すると、クエリ実行が高速になります。 COPYコマンドは、初期ロード時にデータをソートしてテーブルに格納するので、別途VACUUMは不要です。

VACUUMは高価な操作になる可能性があるので、ピーク時以外にコマンドを実行し、VACUUMコマンドを使用可能なメモリ量を増やしてより高速に実行したい場合があります。 VACUUMの詳細については、Amazon Redshift 開発者ガイドのテーブルのバキューム処理を参照してください。

さらに、大量のデータをロードした後でテーブルを分析すると、クエリプランナがクエリプランを構築および最適化するときに使用する統計情報を更新するため、クエリのパフォーマンスが向上します。 COPYコマンドを使用してデータをロードする場合、STATUPDATE ONオプションを指定すると、データの読み込みが開始された後に自動的にANALYZEが実行されます。

VACUUMと同様に、ANALYZEコマンドもリソースを集中的に使用するため、ピーク時以外に実行します。 VACUUMとANALYZEの両方を実行する場合は、VACUUMを最初に実行します。これは、ANALYZEによって生成された統計に影響するためです。詳細については、Amazon Redshift 開発者ガイドの[テーブルを分析する]（https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/t_Analyzing_tables.html）を参照してください。

複数のファイルをテーブルにロードしようとしていて、そのファイルがソート・キーの順序に従う場合は、ファイルのCOPYコマンドをその順序で実行する必要があります。たとえば、20130810.csv、20130811.csv、20130812.csvが異なる3日間のデータを表し、ソートキーがdatetimeであるとします。その後、20130810.csv、20130811.csv、20130812.csvの順番でCOPYコマンドを実行することで、VACUUMを実効する必要がなくなります。